lib/features/orders/presentation/bloc/order_bloc.dart (3)

36-36: Provide user-friendly error messages in OrdersError state

When emitting the OrdersError state, consider providing a user-friendly error message instead of the raw failure message.

Modify the emitted error message to be more user-friendly.

---

63-63: Provide user-friendly error messages in OrdersError state

When emitting the OrdersError state after a failed order update, consider providing a user-friendly error message.

Modify the emitted error message to be more informative for the user.

---

67-67: Ensure state consistency after order update

After successfully updating an order, the bloc adds a LoadOrders event. This could cause unnecessary reloading. Consider updating the local state directly to reflect the change without reloading all orders.

Refactor the state management to update the specific order in the current state.

lib/features/orders/data/repositories/order_repository_impl.dart (1)

66-66: Avoid using null in Right for void return types

Returning Right(null) may be confusing. Instead, use Right(unit) from the dartz package to represent a successful void result.

Apply this diff:

- return const Right<Failure, void>(null);
+ return Right<Failure, void>(unit);

lib/features/orders/presentation/widgets/order_item.dart (3)

58-64: Ensure color contrast for accessibility

The color used in the status label background and text should have sufficient contrast to be readable by users with visual impairments.

Consider reviewing the color choices to ensure accessibility compliance.

---

85-97: Consider default case handling in _getStatusColor

While all OrderStatus enum values are currently handled, adding a default case can prevent potential issues if new statuses are added in the future.

Apply this diff to include a default case:

      switch (status) {
        // existing cases
+     default:
+       return Colors.grey;
      }

---

41-45: Truncate long business names to prevent overflow

Ensure that very long business names do not cause layout issues by adding ellipses or limiting the maximum lines.

The current code uses maxLines: 1 and overflow: TextOverflow.ellipsis, which is good.

lib/features/orders/data/datasources/order_local_data_source.dart (1)

63-64: Consider wrapping deletions in transactions for data integrity

While you're already using a transaction, ensure that deletions are properly handled to prevent partial data states.

Review the transaction handling to ensure atomicity.

lib/features/orders/domain/repositories/order_repository.dart (1)

6-12: Consider adding documentation comments.

Adding documentation comments (///) for the abstract class and its methods would improve code maintainability and IDE support.

+/// Repository interface for managing orders.
 abstract class OrderRepository {
+  /// Retrieves a list of orders.
+  /// Returns a [Future] that completes with either a [Failure] or a [List] of [Order].
   Future<Either<Failure, List<entities.Order>>> getOrders();
 
+  /// Updates the status of an order.
+  /// 
+  /// Parameters:
+  /// - [orderId]: The unique identifier of the order
+  /// - [newStatus]: The new status to be applied
+  /// 
+  /// Returns a [Future] that completes with either a [Failure] or void.
   Future<Either<Failure, void>> updateOrderStatus(
     String orderId,
     entities.OrderStatus newStatus,
   );
 }

lib/features/orders/domain/usecases/get_orders.dart (1)

7-15: Consider using NoParams for consistency with clean architecture.

The implementation looks good, but for consistency with clean architecture patterns, consider using a NoParams class for the call method.

 class GetOrders {
   const GetOrders(this.repository);
 
   final OrderRepository repository;
 
-  Future<Either<Failure, List<order_entity.Order>>> call() async {
+  Future<Either<Failure, List<order_entity.Order>>> call(NoParams params) async {
     return repository.getOrders();
   }
 }
+
+/// Represents no parameters for use cases that don't require input
+class NoParams extends Equatable {
+  @override
+  List<Object?> get props => [];
+}

lib/core/utils/date_utils.dart (1)

20-21: Consider adding documentation and examples.

The new method looks good, but would benefit from documentation similar to other methods in the class.

+  /// Formats the given date and time into a string in the format "d MMM y, HH:mm".
+  /// Example output: "27 Apr 2023, 14:30"
   static String formatDateTime(DateTime dateTime) {
     return DateFormat('d MMM y, HH:mm').format(dateTime);
   }

lib/features/orders/presentation/bloc/order_state.dart (1)

24-31: Consider adding @immutable annotation.

The OrdersError state implementation looks good, but could benefit from explicit immutability annotation.

+import 'package:meta/meta.dart';

+@immutable
 class OrdersError extends OrderState {
   const OrdersError(this.message);

lib/features/orders/domain/usecases/update_order_status.dart (1)

17-28: Consider adding toString override for debugging.

The params class implementation looks good but could benefit from a toString override for better debugging experience.

   @override
   List<Object?> get props => <Object?>[orderId, newStatus];
+
+  @override
+  String toString() => 'UpdateOrderStatusParams(orderId: $orderId, newStatus: $newStatus)';

lib/features/orders/domain/entities/order.dart (1)

3-24: Add documentation and serialization methods to OrderStatus enum

Consider adding:

1. Documentation comments explaining each status and valid state transitions
2. A fromString factory constructor for safe deserialization

/// Represents the possible states of an order in the system.
enum OrderStatus {
  /// Initial state when order is created
  pending,
  /// Order has been confirmed by business
  confirmed,
  /// Order is ready for pickup/delivery
  ready,
  /// Order has been delivered/picked up
  completed,
  /// Order has been cancelled
  cancelled;

  /// Creates an OrderStatus from a string representation
  static OrderStatus fromString(String status) {
    return OrderStatus.values.firstWhere(
      (s) => s.name == status,
      orElse: () => throw ArgumentError('Invalid status: $status'),
    );
  }

  String get displayName => name[0].toUpperCase() + name.substring(1);
}

lib/features/orders/presentation/screens/order_list_screen.dart (1)

26-26: Consider adding pull-to-refresh functionality

The LoadOrders event is only dispatched once when the screen builds. Consider adding pull-to-refresh for better UX.

RefreshIndicator(
  onRefresh: () async {
    context.read<OrderBloc>().add(LoadOrders());
  },
  child: ListView.builder(...),
)

lib/features/orders/data/models/order_model.dart (1)

56-81: Add copyWith method to OrderItemModel

For better immutability support, consider adding a copyWith method.

OrderItemModel copyWith({
  String? id,
  String? name,
  int? quantity,
  double? price,
}) {
  return OrderItemModel(
    id: id ?? this.id,
    name: name ?? this.name,
    quantity: quantity ?? this.quantity,
    price: price ?? this.price,
  );
}

lib/features/orders/presentation/screens/order_details_screen.dart (2)

35-51: Consider improving status indicator accessibility.

The status indicator's color opacity of 0.1 might not provide sufficient contrast for all users. Consider:

1. Increasing the background opacity
2. Adding a semantic label for screen readers

 Container(
   padding: const EdgeInsets.symmetric(
     horizontal: 12,
     vertical: 6,
   ),
   decoration: BoxDecoration(
-    color: _getStatusColor(order.status).withOpacity(0.1),
+    color: _getStatusColor(order.status).withOpacity(0.15),
     borderRadius: BorderRadius.circular(16),
   ),
   child: Text(
     order.status.displayName,
+    semanticsLabel: 'Order status: ${order.status.displayName}',
     style: theme.textTheme.titleMedium?.copyWith(
       color: _getStatusColor(order.status),
       fontWeight: FontWeight.w500,
     ),
   ),
 ),

---

112-125: Consider future-proofing status colors and theme integration.

The current implementation could be improved by:

1. Adding a default case for future status values
2. Using theme colors instead of hardcoded ones

 Color _getStatusColor(order_entity.OrderStatus status) {
   switch (status) {
     case order_entity.OrderStatus.pending:
-      return Colors.orange;
+      return Theme.of(context).colorScheme.warning ?? Colors.orange;
     case order_entity.OrderStatus.confirmed:
-      return Colors.blue;
+      return Theme.of(context).colorScheme.primary;
     case order_entity.OrderStatus.ready:
-      return Colors.green;
+      return Theme.of(context).colorScheme.success ?? Colors.green;
     case order_entity.OrderStatus.completed:
-      return Colors.purple;
+      return Theme.of(context).colorScheme.tertiary ?? Colors.purple;
     case order_entity.OrderStatus.cancelled:
-      return Colors.red;
+      return Theme.of(context).colorScheme.error;
+    default:
+      return Theme.of(context).colorScheme.primary;
   }
 }

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify that all orders have 'completedAt' set appropriately.

# List orders without 'completedAt' where status is 'completed'
sqlite3 orders.db "SELECT id FROM orders WHERE status = 'completed' AND completedAt IS NULL;"

#!/bin/bash
# Let's analyze how completedAt is handled in the codebase

# Find all references to completedAt field
rg "completedAt" -A 3 -B 3

# Also check for any database schema definitions
fd "schema|model" --type f

#!/bin/bash
# Search for the repository implementation to verify error handling
ast-grep --pattern 'class $_ implements OrderRepository {
  $$$
  Future<Either<Failure, void>> updateOrderStatus($_, $_) {
    $$$
  }
  $$$
}'

#!/bin/bash
# Let's try a broader search for OrderRepository implementations
rg "implements OrderRepository" -A 10

# Also search for the updateOrderStatus method
rg "updateOrderStatus.*Failure.*void"

#!/bin/bash
# Let's look at the complete implementation file to see the updateOrderStatus method
cat lib/features/orders/data/repositories/order_repository_impl.dart